Carrier Ethernet is evolving to support the needs of the carrier network environment. Carrier Ethernet requires scalable, reliable, and dynamic mechanisms to support operations, administration, and management (OAM) and traffic engineering (TE). Standards have been developed in the Metro Ethernet Forum (MEF), International Telecommunication Union (ITU), Institute of Electrical and Electronics Engineers (IEEE), and the like providing many of these required extensions. Specifically, Connectivity Fault Management (CFM) is an Ethernet standard to provide many common OAM functions associated with underlying network transport for services. For example, CFM is defined in IEEE 802.1ag-2007 IEEE Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management, the contents of which are herein incorporated by reference. Also, OAM functions are also defined in ITU-T G.8013/Y.1731 (July/2011) “OAM functions and mechanisms for Ethernet based networks,” the contents of which are herein incorporated by reference. Further, the MEF also defines Ethernet OAM in various technical specifications, such as MEF 17 (April/2007) “Service OAM Requirements & Framework,” the contents of which are herein incorporated by reference. Variously, CFM enables definition of maintenance domains, their constituent maintenance points, and the managed objects required to create and administer them; definition of relationships between maintenance domains and the services offered by Virtual Local Area Network (VLAN)-aware bridges and provider bridges; description of protocols and procedures used by maintenance points to maintain and diagnose connectivity faults within a maintenance domain; and the like.
CFM includes Continuity Check Messages (CCM) which may generally be referred to as “heart beat” messages for CFM. That is, CCMs provide a mechanism to detect connectivity failures in a Maintenance Entity Group (MEG) or a Maintenance Association (MA). CCMs are multicast messages that are confined to a MEG Level or a Maintenance Domain (MD). These messages are unidirectional and do not solicit a response. Each Maintenance End Point (MEP) transmits a periodic multicast CCM inward towards the other MEPs. Conventionally, CCM related attributes are statically configured in IEEE 802.1ag-2007, G.8013/Y.1731, and the MEF. In order to change the attributes, static reconfiguration is required. Also, MEPs are statically configured in IEEE 802.1ag-2007, G.8013/Y.1731, MEF 17, etc. In order to add or remove a MEP from a MEG or a MA, static reconfiguration is also needed.
The disclosure herein addresses problems caused by the requirement for such static reconfiguration. For example, such static reconfiguration required by the prior art systems adds complexity, especially with the large scale of proactive service OAM sessions. Further, either from complexity, or time allowed (for uncontrolled cases), it is difficult to protect service traffic during such static reconfiguration.